The present invention relates generally to analysis and debugging of integrated circuit devices. More specifically, the present invention relates to synchronizing the debugging of a processor and a PLD embedded on a common chip.
Since their inception, digital systems have progressed towards higher levels of integration. Higher integration produces several benefits including increased performance and lower development costs. At the device level integration has been achieved by combining functions once performed by multiple individual devices into higher density devices with greater capabilities.
Architectural and process enhancements as well as incorporation of memory onboard the microprocessor chip have permitted microprocessors to operate at higher speeds and with greater capabilities. Likewise, programmable logic devices have matured to meet customer""s expectations of greater capacity and performance through increases in size and density and by changes in architecture. Programmable logic devices refer to any integrated circuit that may be programmed to perform a desired function and include programmable logic arrays (PLAs), programmable array logic (PAL), field programmable gate arrays (FPGA), complex programmable logic devices (CPLDs), and a wide variety of other logic and memory devices that may be programmed. The increased size and capabilities of the devices, with their corresponding complexities, has resulted in movement towards higher levels of abstraction in the design development of microprocessors and programmable logic devices. Programming languages used in conjunction with the design development of microprocessor circuits have evolved towards languages using higher levels of abstraction, such as C, C++, and JAVA. High level hardware description languages, including Verilog and VHDL, are typically employed to develop designs in programmable logic devices. The increased complexity of these devices has also resulted in increased reliance on design verification through on-chip debugging tools. Such tools as Background Debug Mode, Enhanced JTAG, and N-Wire are used in debugging microprocessors.
Traditional design approaches include combining a microprocessor with off-the-shelf devices on a system board. This approach presents problems such as increased delay from signals travelling off chip to other devices and increased power consumption. On the other hand, integrating an embedded processor with programmable logic within a PLD provides several advantages in addition to increased performance. Flexibility is given to the designer to determine which functions should be executed in software (by the processor) and which would benefit form hardware implementation in the PLD. Debugging such a system on a programmable chip (xe2x80x9cSOPCxe2x80x9d) presents unique problems best described after a more detailed description of conventional debugging approaches for PLD""s and microprocessors (software debugging).
In the field of electronics, various electronic design automation (EDA) tools are useful for automating the process by which integrated circuits, multi-chip modules, boards, etc., are designed and manufactured. In particular, electronic design automation tools are useful in the design of standard integrated circuits, custom integrated circuits (e.g., ASICs), and in the design of custom configurations for programmable integrated circuits. Integrated circuits that may be programmable by a customer to produce a custom design for that customer include programmable logic devices (PLDs). Often, such PLDs are designed and programmed by a design engineer using an electronic design automation tool that takes the form of a software package. These tools commonly offer the designer the option of inputting the design in at least one high level hardware description language.
In the course of generating a design for a PLD, programming the PLD and checking its functionality on the circuit board or in the system for which it is intended, it is important to be able to debug the PLD because a design is not always perfect the first time. Before a PLD is actually programmed with an electronic design, a simulation and/or timing analysis may be used to debug the electronic design. However, once the PLD has been programmed and is operating within a working system, it is also important to be able to debug the PLD in this real-world environment.
And although a simulation may be used to debug many aspects of a PLD, it is nearly impossible to generate a simulation that will accurately exercise all of the features of the PLD on an actual circuit board operating in a complex system. For example, a simulation may not be able to provide timing characteristics that are similar to those that will actually be experienced by the PLD in a running system; e.g., simulation timing signals may be closer or farther apart than what a PLD will actually experience in a real system.
In addition to the difficulties in generating a comprehensive simulation, other circuit board variables such as temperature changes, capacitance, noise, and other factors may cause intermittent failures in a PLD that are only evident when the PLD is operating within a working system. Still further, it can be difficult to generate sufficiently varied test vectors to stress the PLD design to the point where most bugs are likely to be observed. For example, a PLD malfunction can result when the PLD is presented with stimuli that the designer did not expect, and therefore did not take into account during the design and simulation of the PLD. Such malfunctions are difficult to anticipate and must be debugged in the context of the complete system. Thus, simulation of an electronic design is useful, but usually cannot debug a PLD completely.
One approach to debugging a hardware device within a working system is to use a separate piece of hardware equipment called a logic analyzer to analyze signals present on the pins of a hardware device. (For example, the HP1670A Series Logic Analyzer from Hewlett-Packard Company.) Typically, a number of probe wires are connected manually from the logic analyzer to pins of interest on the hardware device in order to monitor signals on those pins. The logic analyzer captures and stores these signals. However, the use of an external logic analyzer to monitor pins of a hardware device has certain limitations when it comes to debugging such a device. For example, such an external logic analyzer can only connect to and monitor the external pins of the hardware device. Thus, there is no way to connect to and monitor signals that are internal to the hardware device. Unfortunately, when programming a hardware device such as a PLD, it would be useful to be able to monitor some of these internal signals in order to debug the PLD.
Although some custom hardware devices may come ready made with some internal debugging hardware, this debugging hardware is typically hardwired to route specific internal signals and cannot be readily changed by an engineer who wishes to look at other signals. Also, with such built-in debugging it is not possible to choose any signal to monitor that the engineer desires, nor can triggering signals and triggering conditions be changed by the engineer. Because a PLD by its very nature is a programmable device that an engineer is attempting to program to perform a particular function, it is important to the engineer to be able to customize monitored signals, trigger signals, and trigger conditions in order to efficiently debug any particular device. Further, creating an electronic design for a PLD is an iterative process that requires creative debugging by an engineer who may wish to view almost any internal signal, and who may change his mind fairly frequently in the course of debugging a PLD within a system. Known external and internal logic analyzers do not provide this flexibility.
A further drawback to using an external logic analyzer or hardwired predetermined debugging hardware inside of a custom chip is that often the number of internal signals that an engineer desires to monitor are greater than the number of available pins on the device. For example, if there are sixteen internal signals that an engineer wishes to monitor on a device, he is unable to do this using an external logic analyzer if the device has only four pins available for debugging.
In some cases, it is possible for an engineer to employ a conventional logic analyzer to study an internal signal of a PLD. This may be accomplished by, for example, an engineer modifying his design so that a normally internal signal is routed temporarily to an output pin of the PLD. The design is then recompiled. The engineer then attaches a probe to this output pin in order to monitor the xe2x80x9cinternalxe2x80x9d signal. Unfortunately, the engineer must recompile his design and reprogram the PLD in order to view this internal signal. Also, when debugging is complete, the engineer must again rewrite the design to remove the internal signal from the output pin, recompile the design and finally reprogram the PLD again. This can be a tedious process.
Even if an engineer is successful in routing an internal signal to an output pin of a PLD, with certain integrated circuit packages it may be extremely difficult to attach an external logic analyzer. For an integrated circuit in a dual in-line package it may be relatively straightforward to attach the probes of a logic analyzer to the top of the package as long as the package is in an easily accessible location on a circuit board. However, if the package is in a difficult to reach location because of device crowding, it may be difficult to physically attach logic analyzer probes to particular output pins of interest. Even more troublesome are integrated circuits with rows of miniature contacts located on the top of the package (e.g., xe2x80x9cflip chipsxe2x80x9d). It is difficult to attach logic analyzer probes to particular outputs of interest with this type of package. Some integrated circuit are encased in a ball grid array package with the contacts located on the bottom of the package up against the circuit board; for these packages, it may be nearly impossible to attach logic analyzer probes to these small contacts located on the underside of the package. Thus, use of an external logic analyzer has shortcomings even if an internal signal can be routed to a pin of a device.
U.S. patent application Ser. No. 08/958,435 entitled xe2x80x9cEmbedded Logic Analyzer For A Programmable Logic Devicexe2x80x9d discloses an advantageous apparatus and techniques that allow an embedded logic analyzer to flexibly analyze internal signals of interest in an electronic design, such as within a programmable logic device (PLD). Nevertheless, there is room for improvement in the analysis of internal signals of a PLD for debugging purposes.
For example, some logic analyzers allow a user to specify a trigger condition and a set of trigger signals that must satisfy that trigger condition before the logic analyzer is triggered into the capture of data. Such logic analyzers are useful when it is desirable to capture and analyze signal data that occurs immediately after a particular trigger condition (such as a failure of the device). It is often desirable, however, to capture signals for later analysis that occur before the trigger condition. For the most part, these logic analyzers that begin data capture based upon satisfaction of a trigger condition are unable to provide captured signals before the trigger condition because the logic analyzer is only designed to begin capture upon an error, failure or other trigger condition. Because these errors and/or failures are unanticipated, these type of logic analyzers are unable to anticipate the trigger condition, and hence, are unable to begin capturing data before the trigger condition occurs.
In some debugging situations, it can be extremely advantageous to capture signals that occur before the trigger conditions occurs. For example, when debugging a PCI bus interface, a situation may occur in which the interface enters an illegal state. Traditional logic analyzers would be able to detect that illegal state and immediately begin capturing signal data for later analysis. It would be extremely desirable, however, to begin capturing signal data before the bus interface enters the illegal state in order to determine why the bus has entered this illegal state. In another example, when an interrupt occurs, it can be extremely desirable to know the history of certain registers before the interrupt occurs. In other words, once the interrupt is received, data capture may begin, but the registers may already be in an incorrect state. It would be extremely desirable to be able to capture and analyze signal data before the interrupt occurs in order to determine why certain registers are in an incorrect state when the interrupt occurs. Other situations in which it would be desirable to capture signal data before a specific trigger condition are also possible.
Various prior art efforts present partial solutions, but each have their drawbacks. For example, external logic analyzers available from the Hewlett-Packard Company allow capture of signal data before a trigger condition (or breakpoint) occurs. Unfortunately, these external logic analyzers suffer from many of the disadvantages associated with external logic analyzers discussed above. Actel Corporation of Sunnyvale, Calif. provides two probes within a programmable logic device that are able to monitor two different signals, but these signals must be prespecified by the user and may not be flexibly reassigned to other signals. In addition, the Actel probes provide constant monitoring of particular signals, but do not allow capture of relevant signal data in relation to a specified breakpoint.
As described earlier in this section, a design engineer designs a PLD and programs such a device using an electronic design automation tool. In the course of this design phase, the design engineer may perform numerous design-program-debug iterations before the design is complete and the PLD ready for mass manufacturing. The design engineer often uses a simulation and/or a timing analysis to assist in debugging the electronic design of the PLD. It is also conceivable that a design engineer would use an embedded logic analyzer (such as disclosed in U.S. patent application Ser. No. 08/958,435) to troubleshoot the design. Once the design of the PLD is complete to the design engineer""s satisfaction, the design is handed off to a product engineer for the manufacturing phase.
In the manufacturing phase, a product engineer designs a manufacturing flow for the mass production of an electronic circuit board or other electronic device that incorporates one or more PLDs. During the manufacturing phase, it will be necessary to test the board itself and may also be necessary to retest the PLD. In the beginning of the manufacturing phase, any number and type of hardware components and any number of PLDs are soldered to a board. Once on the board, a PLD is most often programmed (or configured) using a JTAG port located on the PLD. It is also possible that a particular PLD be programmed by itself before placement on a board using a special socket and a programming unit.
A full board test may then be performed to test the traces, solder connections, and other physical interfaces between components on the board. It should be pointed out that a board test may also be performed before any devices on the board are programmed or configured. It is common to use a JTAG port of a PLD or other device to test the traces and solder connections of a board during this board test. Once physical connections are tested, a complete functional test of the board is then formed to test the overall functionality of the board (i.e., to ensure that particular inputs produce the outputs expected). At this point, if a failure is detected it may be necessary to debug a particular PLD while on the board. For failures more difficult to track down, it may even be necessary to remove a PLD from the board to be debugged. In these circumstances, as previously explained, it is desirable to have an embedded logic analyzer within the PLD to facilitate debugging. During any debugging of the PLD using an embedded logic analyzer, it is necessary in some fashion to control the embedded logic analyzer, i.e., to provide it with commands and data and to receive captured data and status from it.
For example, it may be possible to use existing input/output pins of a device to provide a control interface. Unfortunately, a particular design may not have enough extra input/output pins available through which an interface can be provided to control an embedded logic analyzer. It can be undesirable to require that a customer purchasing a PLD not use a certain number of input/output pins simply because the PLD may not have been designed correctly and might have to be debugged at some point.
Embedded logic analyzers placed in the programmable logic device permit capture of specified signal data both before and after a specified breakpoint. However, such embedded analyzers have typically been designed to measure signal levels at various internal: and external circuit nodes within the PLD. Their signal acquisition capabilities do not extend to the states in the software environment of the processor.
Software debug support is particularly useful with embedded processors. In contrast to the signals measured by logic analyzers in a PLD, the state of the microprocessor at the time of a system stoppage can be examined post stop. A debug feature such as single-step may be used to look at the contents of memory accessible by the processor and registers as well as the changes in values at these locations. Through the use of the debugger, values in memory and registers may be modified and followed by a restart of the processor. Breakpoints may be inserted by the debugger (as controlled from the host computer) into points of interest in the program, i.e. where the program is about to perform improperly or has performed improperly. The user may then single step through the program, i.e. use the debugger to execute one instruction at a time, watching the values in registers and memory locations at each step. Debugging may also be used, once a breakpoint is reached, to allow the user to examine the states of all registers and memories leading up to the system stoppage to obtain a more complete picture of the events leading to the system failure.
One type of breakpoint is inserted by a special unit that stops the processor when it is about to execute an instruction at a particular address. A second type of breakpoint involves replacing one of the instructions in the program with a breakpoint.
Extra information can be obtained by analysis of the instructions executed immediately before the system stoppage. Captured software trace data reflects the executed instructions in a processor prior to a trigger. In one approach, a trace capture unit operates in combination with a main processor. The main processor fetches instructions while the trace capture unit monitors fetched instructions and data on the bus and sends the information to the host computer typically in a compressed form. The amount of and format of trace information supplied is typically controlled through a JTAG (Joint Test Action Group) port to an external host computer.
These approaches are not optimal because generally they capture no information about the states in peripherals or other circuitry such as a PLD connected to the processor.
Intel Corporation of Santa Clara, Calif. uses a JTAG port to control access to specified debug registers for help in debugging a central processing unit (CPU). Because a CPU is a known design, it is known beforehand exactly how many debug registers will be needed and control is simplified. With a PLD, however, each user-implemented design will be custom; it is unknown ahead of time what that design will be and how many debug registers might be needed. Those devices that include both a micro processor and a PLD are a greater challenge.
Debugging a chip which combines both a microprocessor and a PLD presents problems which have heretofore been unaddressed. When execution of instructions in the microprocessor comes to a halt, either through program failure or through activation of a breakpoint in debugging software, the operations in the PLD logic will continue indefinitely. Thus, the logic states observed in the PLD at the time that execution terminates will be different from the states (of instructions) observed on the processor side at the time that the system fault occurred. This incongruence between states may also occur when a fault in the PLD side occurs. Although debugging trace results can be obtained independently for the microprocessor and the PLD, there is a need for matching those results so that the states of the entire system, including the microprocessor instructions and the PLD logic signals, can be inspected at the time of the system fault.
The microprocessor portion of the chip will typically have an optimal clock speed different from the maximum clock speed of the PLD. This means each of the portions will operate at different speeds and the traces for each of the portions will have different clock periods. This adds to the difficulties in attempting to get a complete picture of the states of the PLD logic and the processor instructions at selected times during the debugging process. Therefore, what is further needed is a method of synchronizing debugging trace results for both the microprocessor and the PLD logic so that the states of the entire system at a trigger time and a selected period before or after the trigger may be accurately analyzed.
To achieve the foregoing, and in accordance with the purpose of the present invention, a technique and electronic device for synchronizing logic signals captured in a PLD portion of a PLD system having both a microprocessor and PLD circuitry with executed instructions captured from a microprocessor portion, is disclosed. One or more signal lines connects the microcontroller portion with the PLD portion for transmitting signals between the two portions corresponding to debug operations in each portion.
Combined processor and PLD systems employ independent clocks for each portion to optimize performance of each portion. Although software debuggers are commercially available and capable of capturing and storing thousands of instructions in accordance with the available memory, they have no capability of storing the states present in the PLD logic. Embedded logic analyzers such as Altera""s Signal Tap are capable of storing signal values for selected logic circuit points but are incapable of capturing and storing the executed instructions in the associated embedded microprocessor. The present invention solves these problems by providing a direct signal from the PLD portion to the microcontroller portion upon the occurrence of events relating to debugging and debug modes of the microprocesssor. In one embodiment, the PLD portion is configured to send the output from a counter to a trace module in the microcontroller portion in order to perform synchronization. The periodic and variably valued output signal from the PLD portion enables software in an external host computer connected to the combined circuit to match a debug trace from the microprocessor to selected events occurring within the PLD portion. In another embodiment, a signal is transmitted from the microcontroller portion to the PLD portion and an embedded logic analyzer is configured to respond to the signal by performing a post-trigger capture trace. This trace captures the states of selected logic in the PLD portion and may provide the data to a user through software operating on a host computer connected to the PLD portion, often through a JTAG port.